Most computer systems store data by physically encoding it as a data file on a storage device such as a hard magnetic disk. The software tools used to perform this storage and the subsequent access to, or manipulation of, the data file, are provided by a routine called a file system manager which is usually included in an operating system.
An operating system is a program or collection of programs which allow control of the computer's physical devices. In a UNIX™-based system, the operating system interacts directly with the hardware providing common services to programs and isolating the software and users from the hardware idiosyncrasies of a particular computer system. For example, the operating system may coordinate the sending of information to a printer to be printed, or commence the operation of an application program. Operating systems also have some manner of interface to communicate with the user, generally via a command line on the computer's monitor where the user can enter an instruction from the operating system's instruction set, or via a graphic user interface which presents a simpler means of entering the same kinds of instructions.
The file system management functions of the operating system (or simply, the file system manager) provides a standardized means of storing and accessing data on storage subsystems, being responsible for handling all requests to open, close, read, and write files. These data files are referred to by symbolic filenames which tell the operating system where the data can be physically found. HPS, FAT, FAT32, NTFS and HPFS are common file systems used on personal computers.
In many computer systems, data files are sorted into a structure of folders, directories, subdirectories or similar categories, making them easier to identify and locate. In these systems, each file has a unique path name which identifies its location within the file structure, access to the data generally starting at the top and proceeding through the levels of the hierarchy. Most operating systems use these types of tree-like or hierarchical filing systems, including the UNIX, MS-DOS™, OS/2™, Windows™ NT™, 95™ and 98™, and Macintosh™ operating systems.
UNIX and MS-DOS computers, for example, have a “root” directory from which all other directories or sub-directories branch out. The syntax of the path name is usually a sequence of directory or filenames separated by the “/” character, each subsequent entry representing another level of the tree. For example, referring to FIG. 1, the path name “/main/songs/myfile” identifies a file named “myfile” that is located in the “songs” subdirectory, which is located in the root directory “main”. Often the organization and revisions of software applications are built into the path names.
A typical UNIX environment has a single file system. In a network environment which includes several users, there still may be only one file system, referred to as a Network File System (NFS). Typical file systems suffer from a number of problems which result in the inefficient use of computer and network resources, and difficulties in their use.
In most environments, for example, the users do not require access to all of the available files on a regular basis, rather they use a small subset. Hence, existing file systems present a large volume of unneeded information which only serves to obscure the files the user is trying to locate. In an attempt to address this problem, personal subdirectories are used to store personal files such as archived email and word processing documents, placing them in an easily identifiable location. Personal subdirectories may also be implemented with access restrictions, for example, allowing access only by the particular user and the system administrator.
However, personal subdirectories do not solve the problem of managing applications software. While storing separate copies of applications software for each user in a personal location would allow users or systems to easily locate the software and safely make modifications, it would be tremendously demanding of system resources. Clearly, this method would not scale well for larger networks, and it would take a great deal of time to implement a version upgrade as all of the personal copies would have to be upgraded separately. Furthermore, it would be quite easy to lose track of software versions, or confuse older versions of programs with new versions.
There is also the possibility that users or systems will modify or damage files which should not be changed as other users or systems require them to be in their original form. This can be prevented by designating files as write-protected which prevents any modifications from being stored, but some files must be modified by other software programs to operate properly, so they cannot be protected in this way. Hence, to avoid accidental and permanent damage to an original file, it is common to create a personal copy of a file the user wishes to modify. If this file ever becomes damaged it can always be replaced with another copy of the original. As noted above, this method is very resource intensive as the storage memory must store a separate copy of the software for each of the end users. This solution is not scalable or flexible, and results in a inconsistent number and location of software versions which is very difficult to administer.
Another file management problem is the administration of software products that are available in many versions, as new features are added or performance is improved. Each version will typically rely on a separate set of source code, including components such as libraries, patches and support files. An example is presented in FIG. 2, where three software packages are stored in a “drawing” subdirectory: first and second versions of a drawing package (draw—1.4 and draw—2.0 respectively), and a format converting package (convert—2.2). Related files are also stored in this subdirectory: software tool sets for the two drawing packages (drtools—1.4 and drtools—2.0), a software patch for the first drawing package (drpatch—1.4), and a font set for the second drawing package (drfont—2.0). As software applications often consist of dozens of files which are installed with numerous subdirectories, it is clear that the management of these files can be immensely more complex than that suggested by this example.
An example of such a set of subdirectories is presented in FIG. 3, for the software application of “draw—1.4” (for the sake of simplicity, the two higher levels “main” and “drawing” are not shown). This application has two top-level directories “bin” and “etc” which are platform independent, and might contain files such as shell scripts in the “bin” subdirectory and configuration files in the “etc” subdirectory. A directory may have any arbitrary name, but the convention is for a “bin” directory to be one which contains files stored in binary format, that is, computer-readable and not human-readable files. This application also has three top-level directories which are hardware architecture platform dependent: “x86”, “mips” and “ppc”. For platform-specific files, the CPU type is encoded as part of the pathname, for example, for x86-specific binaries, the pathname x86/bin is used. The balance of the identified directories store related files required by the draw—1.4 application, both the /mips/ and /ppc/ subdirectories, of course, having similar structures to that of the /x86/ subdirectory.
When a network administrator attempts to perform a system-wide upgrade of a software application, it may not be desirable or possible for all systems to move to the new version. They may, for example:    1. have legacy software or hardware that is not compatible with the new version;    2. not want to spend time learning how to operate the new version, particularly if it offers then minimal improvements over the last version; or    3. expect difficulty in removing the old version. When an application is removed or uninstalled from the system it is a tedious process to actually remove all of the files which have been modified.Therefore, it may be necessary for the network administrator to make multiple versions of the same software available.
In an effort to simplify the process of software installation and uninstallation, some file systems, such as Microsoft Windows 95 and NT operating systems, use a registry database to store configuration information. Most software applications write data to this registry, particularly during installation. However, these tools actually physically manipulate the software application files on disk when installing, so they require personal copies which vary from one user to the next. Like the proposals noted above, making multiple copies is not a scalable or flexible solution, and results in a inconsistent number and location of software versions which is very difficult to administer.
Hence, there is a need for an improved system and method of computer file management for computers and computer networks. Traditional computer networks included personal computers, laptop computers, terminals, servers, mainframes, scanners, printers, data storage units and the like. The current trend though is to converge many forms of computers, communication devices and appliances onto a single network including personal digital assistants, Internet ready cellular telephones, hardwired telephones, and television set top boxes. This will make the need for such an improved system and method even greater as these devices could potentially run on different architectures and require different binary formats of the same files.